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ABSTRACT 



The present invention provides a method for tokenless 
biometric access to financial accounts at an institution using 
an automated teller machine. This method comprises a user 
registration step, wherein a user registers with an electronic 
idenlicator one or more registration biometric samples and 
one or more user financial accounts. During an initiation 
step, the user initiates an account access at an automated 
teller machine by submitting at least one bid biometric 
sample directly from the user's person, wherein no portable 
man-made memory devices such as smartcards or swipe 
cards are used by the user. In at least one transmission step, 
an account access request message comprising the user's bid 
biometric is forwarded from the automated teller machine to 
the electronic identicator. During a user identification step, 
the electronic identicator compares the bid biometric sample 
in the account access request message with a registration 
biometric sample, to produce either a successful or failed 
identification of the user. Upon successful identification of 
the user, at least one financial account of the user is 
retrieved, and in an access step, after successful identifica- 
tion of the user and successful financial account retrieval, the 
user is allowed to access the user financial account. 

27 Claims, 15 Drawing Sheets 
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TOKENLESS BIOMETRIC ATM ACCESS An example of another token-based biometric smartcard 

SYSTEM system can be found in U.S. Pat. No. 5,280,527 to Gullman 

et al. In Gullman's system, the user must carry and present 

CROSS-REFERENCE a credit card sized token (referred to as a biometric security 

This application is a continuation of application Ser. No. 5 apparatus) containing a microchip in which is recorded 

08/705399, filed on Aug. 29, 1996 now U.S. Pat. No. characteristics of the authorized user's voice. In order to 

5,870,723, which is a continuation-in-part of U.S. applica- initiate the access procedure, the user must insert the token 

tion Ser. No. 08/442,895 filed on May 17, 1995 now U.S. into a such as an ATM, and theD speak into the ATM 

Pat. No. 5,613,012 which is a continuation-in-part of U.S. to provide a biometric sample for comparison with an 

application Ser. No. 08/345,523, filed on Nov. 28, 1994, now i° authenticated sample stored in the microchip of the pre- 

U.S. Pat. No. 5 615 277. sented token. If a match is found, the remote ATM signals 

the host computer that the account access should be 

BACKGROUND permitted, or may prompt the user for an additional code, 

The use of a token, an inanimate object which confers a such as a PIN wnich » also stored on lhe token » before 

capability to the user presenting it, is pervasive in today's is authorizing the account access. 

financial world. At the heart of every transaction is a money Although Gullman's reliance on comparing biometrics 

transfer enabled by a token, such as a plastic debit or credit reduces the risk of unauthorized access as compared to PIN 

swipe card, which acts to identify both the user as well as the codes, Gullman's use of the token as the repository for the 

financial account being accessed. authenticating data combined with Gullman's failure to 

From their inception in the late 1970s, token-based sys- 20 isolate the identity verification process from the possibility 

terns for accessing financial services have grown increas- of tampering greatly diminishes any improvement to fraud 

ingly more prevalent in the banking industry. However, as resistance resulting from the replacement of a PIN with a 

token-based systems access have become more popular with biometric. Further, the systems mains inconvenient to the 

users, they have also become more popular with criminals us er because it requires the presentation of a token in order 

intent on perpetrating fraud. Currently, fraud losses in the 25 to horizon an account access. 

financial industry stem from many different areas, but they Uniformly, the above patent that disclose financial autho- 

are mainly due to either stolen or counterfeit cards. rization systems teach away from biometric recognition N 

Generally, debit cards are used in conjunction with a out the use of tokens. Reasons cited for such teachings range 

personal identification number (PIN). The PIN helps to from storage requirements for biometric recognition systems 

prevent lost or stolen cards from being used by criminals, 30 l ° significant time lapses in identification of a large number 

but over time various strategies have been used to obtain of individuals, even for the most powerful computers. 

PINs from unwary cardholders. Such strategies include Furthermore, any smartcard-based system will cost sig- 

Trojan horse automated teller machines (ATMs) in shopping nificantly more than the current magnetic stripe card systems 

malls that dispense cash but record the PIN, to fraudulent currently in place. A PIN smartcard costs perhaps $3, and a 

debit devices that also record the PIN, to criminals with biometric smartcard will cost S5. In addition, each station 

binoculars that watch cardholders enter PINs at ATMs. The that currently accepts existing debit cards would need a 

subsequently manufactured counterfeit debit cards are then smartcard reader, and if biometrics are required, a biometric 

used in various ATM machines to fraudulently withdraw scanner will also have to be attached to the reader as well, 

funds until the account is emptied. ^ Q This costly price lag has else industry to look for addi- 

User-based fraud for debit cards is also on the rise. Users tional applicalioas of the smartcard beyond simple banking 

intent on this sort of fraud will claim that they lost their card, and debit needs. It is envisioned that in addition to storing 

say that their PIN was written on the card, and then withdraw credit and debit account numbers and biometric or PIN 

money from their account using card, and then refuse to be authentication information, smartcards may also phone 

responsible for the loss. 45 numbers, frequent flyer miles, coupons obtained from stores, 

The financial industry is constantly taking steps to a transaction try, electronic cash usable at toUbooths and on 

improve the security of tokens, such as debit cards and new public transit systems, as well as the user's name, vital 

smartcards. However, the linkage between the user and his statistics, and perhaps even medical records, 

token remains tenuous, and that is the fundamental reason The net result of this "smartening" of the token is increas- 

behind the increasing card fraud. 50 ing centralization of functions and increasing dependence on 

7 One solution that would reduce counterfeit-card fraud lhe token itself, resulting in increased vulnerability for the 

involves using a smartcard that includes a biometric. In this user- Given the number,of functions that the smartcard will 

approach, authenticated biometrics are recorded from a user be performing, the loss or damage of this all-important card 

of known identity and stored for future reference on a token. will be excruciatingly inconvenient for the cardholder. 

In every subsequent account access, the user is required to 55 Being without such a card will financially incapacitate the 

physically enter the requested biometric, which is then cardholder until it is replaced. Additionally, losing a card full 

compared to the authenticated biometric on the token to of electronic cash may also result in a real financial loss as 

determine if the two match in order to verify user identity. well. 

Various biometrics have been suggested for use with Thus, after spending vast sums of money, the resulting 

smartcards, such as fingerprints, hand prints, voice- prints, 60 system will be somewhat more secure, but will levy heavier 

retinal images, handwriting samples and the like. However, penalties on the user for destruction or loss of the card, 

the biometrics are generally stored on a token in electronic To date, the banking industry has had a simple equation 

form, and thus the biometrics can be fraudulently copied and to balance: in order to reduce fraud, the cost of the card must 

reproduced. Because the comparison and verification pro- increase. This cost is passed along to users. As a result, there 

cess is not isolated from the hardware and software directly 65 has long been a need for an ATM access system that is highly 

used by the user attempting access, a significant risk of fraud fraud-resistant, practical, convenient for the user, and yet 

still exists. cost-effective to deploy. 
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There is also a need for an ATM access system that The tokenless biometric access device uses an automated 

identifies the. user, as opposed to merely verifying a user's teller machine, such as those of banks and other financial 

possession of any physical objects that can be freely trans- institutions. An electronic identicator compares, optionally 

ferred. This will result in a dramatic decrease in fraud, as remote from the electronic identicator compares the bid and 

only the authentic user can access his or her account. 5 registration biometric samples of a user to produce either a 

A further need in an account access system is ensuring successful or failed identification of the user. The user 

user convenience by providing access without forcing the submits a biometric sample to the electronic identicator 

user to possess, carry, and present one or more man-made through a biometric input apparatus. The registrant user 

memory devices in order to authorize an account access. All must have at least one financial account, where an account 

parties intent on fighting fraud recognize that any system 10 retrieval module is used to retrieve the registered financial 

that solves the fraud problem must.take the issue of conve- accounts of a user upon successful identification of that user, 

nience into account, however the fundamental yet unrecog- An execution module optionally debits or credits the user's 

nized truth of the situation is, the card itself is extremely financial account. It is understood that the device requires no 

inconvenient for the user. This may not be initially obvious, man made tokens such as cards or smartcards are presented 

but anyone who has lost a card, left a card at home, or had 35 for submitting a bid biometric sample to the electronic 

a card stolen knows well the keenly and immediately-felt identicator. 
inconvenience during the card's absence. 

Yet another need in the industry is for a system that 

greatly reduces or eliminates the need to memorize cum- FIG. 1 is an overview diagram of the preferred embodi- 

bersome codes in order to access ones financial accounts. 20 ment of the system of the present invention; 

Yet another need in the industry is for a system that FIG. 2 is a diagram of the preferred embodiment of the 

eliminates the need to memorize PIN codes. Data Processing Center and its internal databases and execu- 

There is further a need for a system that affords a user the tion modules; 

ability to alert authorities that a third party is coercing the ^ FIG. 3 is a diagram of the ATM terminal, a biometric input 

account access without the third party being aware that an apparatus and components, and the interconnections 

alert has been generated. There is also a need for a system between them; 

that is able to effect, unknown to the coercing third party, FIG. 4 is a flowchart depicting the generation of an 

temporary restrictions on the types and amounts of account acc0UQl accegs f st message; 
accesses that can be undertaken. 

Lastly, such a system must be affordable and flexible 

enough to be operative ly compatible with existing networks m ^ ^ . . . * , 

having a variety of electronic access devices and system FIG. 6 is a visual representation of the account access 

configurations. res P onse messa g e i 

FIG. 7 is a flow chart depicting the data encryption and 

SUMMARY 35 sealing process at the biometric input apparatus; 

The present invention satisfies these needs by providing a FIG- 8 is a flow chart depicting the message decryption 

method for tokenless biometric access to financial accounts a " d the validation process at the DPC; 

at an institution using an automated teller machine. This FIG. 9 is a flow chart depicting the data encryption and 

method comprises a user registration step, wherein a user 40 sealing of an account access response message at the DPC; 

registers with an electronic identicator one or more regis- FIG. 10 is an overview flowchart of the user registration 

tration biometric samples and one or more user financial process; 

accounts. During an initiation step, the user initiates an pjQ 11 is an overview flowchart of the user account 

account access at an automated teller machine by submitting access process; 

at least one bid biometric sample directly from the user's 45 piG. 12 is a flowchart depicting a user identification step 

person, wherein no portable man-made memory devices . me ferred embodiment of biometric and PIN from 

such as smartcards or swipe cards are used by the user. In at me acc0UQt acce&s s( message at the DPC ; 

least one transmission step, an account access request mes- ... „ ...... . , 

■ • .u > u j u- * * • c a a c FIG. 13 is a flowchart depicting the silent alarm process 

sage comprising the user s bid biometric is forwarded from ■ . . rTr,^ 

. ♦ a 7 n u- . .u i . ''a*'* using the account access response message at the DPC; 

the automated teller machine to the electronic identicator. 50 . . ■ , 

During a user identification step, the electronic identicator FJG - 14 15 a flowchart depicting the generation of an 

compares the bid biometric sample in the account access accounl access rec l uest messa g e at the DPC i 

request message with a registration biometric sample, to FIG. 15 is a flowchart depicting the re-registration check 

produce either a successful or failed identification of the step at the DPC; and 

user. Upon successful identification of the user, at least one 55 FIG. 16 is a flowchart depicting the decryption and 

financial account of the user is retrieved, and in an access validation of an account access response message at the 

step, after successful identification of the user and successful BIA. 
financial account retrieval, the user is allowed to access the 

user financial account. • DETAILED DESCRIPTION 

This method preferably includes a method whereby the 60 The invention provides a tokenless method for identifying 
user registers a personal identification number with the users for the purpose of authorizing ATM access for con- 
electronic identicator, which is used by the electronic iden- sumers. It is the essence of this invention that consumers 
ticator to identify the user. conduct these transactions without the use of a personal 

Thus, any financial operation such as withdrawing cash, identification number ("PIN") or any tokens, such as debit 

depositing funds, transferring funds between accounts, 65 cards. 

obtaining account balances, purchasing products, and pay- Turning now to the figures, the overall configuration of 

ing bills is performed. the invention and its components are shown in FIG. 1. 



11/25/2003, EAST version: 1.4.1 



6,154,879 

5 6 

Essentially a electronic identicator Data Processing Center for use in electronic financial transactions and providing 

(DPC) 1 is connected to at least one ATM 2 through various access to financial services. Actions of the BIA are directed 

types of communication means 3. The DPC is also con- by an ATM, which issues commands and receives results 

nected and communicates with independent computer net- over the BIA's serial line. In the preferred embodiment, the 

works. The DPC contains several databases and software 5 BIA is an add-on component for existing ATM devices, 

execution modules as shown in FIG. 2. In a preferred However, in another embodiment, the BIA components are 

embodiment of the invention, the databases are backed up or built in to the ATM at time of manufacture, 

"mirrored" in distinct physical locations for safety reasons « Each BIA has its ^ ue cncryption ^ m 

The Firewall Machine 5 * responsible for prevention of * onl tQ the Dpc afld each BIA is Qm allowed tQ rform 

electronic intrusion of the system while the Gateway w operations to its designated function. Each BIA has 

Machine 6 is responsible for routmg all requests from the ^wrs identification code previously registered with the 

user including adding, deleting and otherwise modifying all BIA uniquely identifiable to the DPC 

databases. In a preferred embodiment, some of the commu- ' , , " H v ' ^ . 

nication between the ATM and the DPC are encrypted for » each subs ^ent transmission from that biometnc input 

enhanced security. The Gateway Machine is also responsible device - 

for decryption and de-packaging of encrypted data that has 157 ATMs 

arrived from the ATMs using the MACM module 7, MDM /C BIAs are preferably fuUy integrated with the ATM. It is 

module 8, and the SNM module 9. The BGL module 10, and preferred that the BIA never disclose any secret encryption 

the IML module (not shown) are used to locate the biometric codes to any external source. 

number. FIG. 3 depicts an example of a ATM 2 and the The BIA hardware is a multichip module combined 
biometric input device 12, which has a biometric scanner 13, 20 preferably with a single-print scanner, a display screen, a 
data entry means such as a key pad 14, and a display panel serial port, and a key pad. The following components are 
15. The biometric scanner can be any one of fingerprint preferably amalgamated into a multichip module, called the 
scanner, voice input device (microphone), palm print BIA Multichip Module (a process for encapsulating several 
scanner, retinal scanner or the like, although the fingerprint processors in one physical shell, well known in the 
scanner will be used as an example. The biometric input 25 industry), constructed to protect the communications path- 
device is further equipped with computing modules 16, ways between the devices from easy wiretapping; Serial 
device drivers, and erasable and nonerasable memory mod- processor) keypad processor, LCD screen processor, CCD, 
ules. The biometric input device commu mcates with the Scanner, A^) processor, High-speed DSP processor contain - 
Am through preferably a serial port 17. T^e ATM 2 . bo ; h fl - fa and ' 

mask, ROM, General-purpose 

communicates through a modem 18 with the DPC 1 through 3Q Standare| and EEPROM . 

messages 19 and responses 20 using one of the intercon- ^ , j j . c i_i 

nectinl means in FIG. 1 such as a cable TV network, cellular ™ e S . aD " ala a £ I ?£^ ly 

telephone network, telephone network, the Internet, or an stored m mask , * 0U > 1^"^^ DVKF J Key 

X 25 network Management library, DES (with CBC) Encryption, library, 

FIG. 4 is a flowchart depicting the generation of an Base-64 (8-bit to printable ASQI) converter library Embed- 

account access request message. FIG. 5 and FIG. 6 show a 35 ded Operating System, Serial line device driver, LCD device 

representational diagram of the account access request and dnver » ke Y P ad device dnver ' Scanner device driver, Unique 

response messages. Furthermore, it is shown which parts of hardware identification code, and Multi-Language profiles, 

the messages are encrypted and which ones are sealed. FIG. The following standard data and software packages are 

7 is a block diagram of the overall process for data encryp- preferably stored in flash ROM. Flash ROM is more 

tion and sealing showing the use of DUKPT key data 20 for 40 expensive, but it is much more difficult to reverse engineer, 

encryption of data before appending additional data before and most importantly, it is electronically erasable. All of the 

sealing the message with a Message Authentication Code more critical information is stored here. Flash ROM is used 

(MAC) 21. FIG. 8 and FIG. 9 show the decryption and in an attempt to increase the difficulty of duplicating a BIA. 

encryption processes at the DPC. FIG. 10 shows the steps . The standard data and software packages include; Unique 

taken during encryption/sealing process at the BIA until the 45 DUKPT Future Key Table, Unique 112-bit MAC Key, DSP 

registration of the user is complete. FIG. 11 describes the biometric quality determination algorithm, DSP biometric 

steps involved in processing an account access request from encoding algorithm, Random number generator algorithm, 

a user, starting from entry of biometric personal authenti- and Command function table. 

cation information at the BIA, all processing by the DPC, The message sequence number, incremented each time a 

and then finally the presentation of results by the BIA. FIG. 50 message is sent from the BIA, is stored in the EEPROM. 

12 describes the user ID process at the DPC. FIG. 13 shows "EEPROM can be erased many times, but is also 

the silent alarm processing. FIG. 14 shows the process for nonvolatile — its contents remain valid across power inter- 

the account access response message construction. FIG. 15 ruptions 

shows the re-registration check step for determination of The following data is stored in RAM. RAM is temporary 

fraudulent re-registration without the use of a PIN. FIG. 16 55 in nature, and its contents are lost whenever power is lost; 

shows the decryption and validation of an account access Encoded Biometric Register, Account Index Code Register, 

response message at the BIA. Amount Register, Message Key, Response Key, 8 General 

Description of the drawings, diagrams, flow charts and the Registers, and stack and heap space, 

description of the invention, including hardware Each multichip module contains a "write-once" memory 

components, software components, execution modules, 60 location that is irreversibly set following the initialization of 

databases, connection means, the data transferred between the flash R0M - Whenever an attempt is made to download 

them, and the method of the invention is described in a software to the flash ROM, this memory location is prefer- 

preferred embodiment below. abl y checked; if it is already been set, then the BIA refuses 

/ to load. Critical software and data keys may only be down- 

\0 Biometric Input Apparatus (BIA) 65 loaded once imo the device> at lhe lime of marju f aclure . 

7 The BIA is a combination of hardware and software All registers and keys are explicitly zeroed when an 

whose job is to gather, encode, and encrypt biometric input account access is canceled. Once an account access is 



11/25/2003, EAST Version: 1.4.1 



6,154,879 

7 8 

completed, registers are cleared as well. Once a "form fingertips. A complete list of minutiae is stored in the DPC 

message" command is executed, biometric and account as a reference, while only a partial list is required by the 

index code registers are also cleared, along with any encryp- algorithm when performing a comparison between an iden- 

tion keys that aren't required for subsequent use. It is tification candidate and a registered user, 

important that the software not keep copies of registers or 5 During both registration as well as identification, the 

keys in stack variables. encoding algorithm must preferably find a reasonable num- 

The following associated hardware components comprise fcer 0 f minutiae points. Otherwise, the BIA will ask for the 

the standard BIA hardware module; BIAMultichip module, biometric to be re-entered. 

CCD single-print scanner, lighted keypad with auxiliary ^ fflA b a utm envir0Dment> and ^ 

buttons, 2-hne 40-column LCD screen RF shielding, 10 such requires a real . t i me embedded operating system to run 

tamper-resistant case, serial connection (up to 57.6 kb), ft ^ Ung system ^ respolls ibie for taking interrupts 

tamper detection hardware. from devices and scheduling tasks. 

All temporary storage and internal hardware and software „ , , . , . 

used to calculate these values are secured, which means they u Each device dnver 1S ^sponsible for the interface 

resist any attempts to determine their current values, or their 15 between the operating system and the specific hardware, 

'r r ... such as the Key pad device dnver, or the CCD Scanner 

means of functioning. * . . r ■ 

device dnver. Hardware is the source for events such as 

BIA Software "Key pad key pressed," or "CCD Scanner scan complete". 

The device driver handles such interrupts, interprets the 

Preferably, the external interface to the BIA is much like events, and then takes action on the events, 

a standard modem; commands are sent to it from a control- ^ m number of D£S ^ lemenlations blicl 

ling ATM using the external serial line. When a command D£S im lemeolations ide a ^ct key . based 

C A TS ^ 3 ? & u! K^Ie^n u encryption from plaintext to ciphertext, and decryption from 

All BIA data fields are preferably in pnntable ASCII, with „ tn „u in uu ™«* 

„ , , . , „ . , i, , ciphertext to plaintext, using 112-bit secret keys, 

fields separated by field separator control characters, and . . 

records separated by newlines. Encrypted fields are binary 25 Pubbc Ke y encryption support hbranes are available from 

converted to 64-bit ASCII using the base-64 conversion ™> hc Ke V Partners > holders of the RS A public key patent 

Ubrary (all known in the industry). ( known ln the 'n dustr y)- Public Key cryptosystems are 

„ . . , - . , asymmetric encryption systems that allow communication 

If, instead of a financial account screen prompt, an , o (ake , ace ^ a cosd exch of 

account index code is used this code can be one or more x k To use a bljc k encrwtion systenli a public key ^ 

alphanumeric characters, which includes numbers, letters, ^ tQ e a DES k and then m( , DES key is used to 

and other characters. For foreign languages, this includes , a m ^ DIA ^ bUc k cry p tosyslems 

multicharacter combinations winch are used to represent tQ ;de for ^ xam exch of sceM k 

specific words or concepts in that language, such as kanji L, . t^tt,™™ 

characters. When instructed, the BIA captures a biometric in „ ™* denved kev l* r transaction key (DUKPT) 

the following way. A fingerprint image is captured and given 35 management library is used to create future DES keys given 

a preliminary analysis by the print quality algorithm. If the an imUal ke y and a me **& s ^ ce number - Future ke y s 

image is not clearly readable by the biometric algorithm «* st0 , rcd m » Futu /, e Ke y. Table - 0nce "f* a g» veQ ke y 15 

software, the BIA continues to take new scans until a clear«I from the table. Initial keys are only used to generate 

predetermined number of seconds pass. As time passes and ^ me lmUal ^ lU £* ey ^ 11l6refore lhe ,mUal ke y 15 no1 

images of are taken and analyzed, messages are posted to the stored by the BIA 

LCD screen and sent to the ATM based on the problems The use of DUKPT is designed to create a key manage- 

detected by the image quality algorithm. If no image of ment mechanism that provided a different DES key for each 

appropriate quality is forthcoming, the BIA returns an error transaction, without leaving behind the trace of the initial 

code of time expired, displaying a message to that effect on key. The implications of this are that even successful capture 

the LCD. an d dissection of a given future key table does not reveal 

The BIA software is supported by several different soft- messages that were previously sent, a very important goal 

ware libraries. Some of them are standard, generally avail- when lhe effective lifetime of the information transmitted is 

able libraries, but some have special requirements in the decades * DUKPT * ^ specified in ANSI X9.24. 

context of the particular biometric used for identification of 50 ATMs 
the user. 

Since the BIA is constandy selecting random DES keys The ATM is the device that controls the BIA and connects 

for use in the message body and message response to the DPC via modem, X.25 packet network, telephone 

encryption, it is important that the keys selected be unpre- network, or a private intranet. Whenever a ATM provides 

dictable keys. If the random number generator is based on 55 information to the system, the system always validates it in 

time of day, or on some other externally-predictable some manner, either through presentation to the user for 

mechanism, then the encryption keys will be much more confirmation, or by cross-checking through other previously 

easily guessed by an adversary that happens to know the registered information. 

algorithm. The security of the encryption techniques used in While ATMs are able to read some parts of BIA messages 

the BIA assumes that both the random number generator go in order to validate that the data was processed properly by 

algorithm as well as the encryption algorithms are both the BIA, ATMs cannot read biometric identification infor- 

publicly known. One such random number algorithm for mation including the biometric, encryption keys, or any 

generating DES keys is defined in ANSI X9.17, appendix C. account index codes. 

The biometric encoding algorithm is an algorithm for BIAs export some security functionality to the ATM, such 

locating identifying or locating the physical characteristic 65 as private code display. The purpose of the BLA-equipped 

feature of a user of the system for example the minutiae that ATM is to provide users access to cash and other ATM 

are formed by ridge endings and bifurcations on human functions without having to use a debit card. It does this by 
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submitting a biometric, retrieving a list of accounts, and Databases 

allowing the user to select a particular account on which to Individual Biometric Database: identifies users either 

perform operations. For users of the system, this replaces the from their biometric or a biometric and PIN IBD 

ATM card+PIN mechanism as a method for identifying the Valid Apparatus Database: stores information required to 

financial account and authorizing the user. It is assumed that 5 validate and decrypt BIA messages. VAD 

all ATMs still continue to accept ATM cards. Apparatus Owner Database: stores information about the 

The BIA-equipped ATM consists of: owners of BIA devices. AOD 

a standard ATM Software 

an integrated BIA Message Processing Module: handles the processing of 

a connection to the DPC 10 each messa 8 e bv coordinating with the other software mod- 

The biometric ATM uses an integrated BIA to identify ^ and databases required to perform the message's task, 

users and allow them access to financial accounts using a M ™ 

biomeinc and an account index code. A BIA is installed into Se /l uence Number Module: handles DUKPT sequence 

the ATM, making use of the ATM's current keypad and number processing. SNM 

account index code entry. The ATM is connected to the 15 Authentication Code Module: handles MAC 

system using its standard debit network connection. The BIA validation and generation MACM 

is structured in such a way as to make integration with an A Messa * e ?™ T W { Module j haDdles c ?E™ Un * and 

existing ATM network as simple as possible. decrypting of BIA requests and responses. MDM 

Three entities need to be identified for the DPC to respond 1BD Machine List: handles the lookup of the mam and 

properly to a BIA account request: the user, the bank, and the backup database machines dedicated to holding IBD records 

BIA. 20 f° r a g» veD biometric group. IML 

The bank is identified by cross-checking the ATM's stored When defining database schema, the following terminol- 

bank code with the BIA's bank code. The BIA is identified ogy is used for describing field types: 

by successfully locating the BIA in the VAD, and the user is int<X> an integral type using <X> bytes of storage 

identified through the standard biometric. char<X> a character array of <X> bytes 

To access an ATM, a user enters their biometric. The BIA 25 text a variable kn ^ h character 

forms a Account Access request message, which is then sent 4 rvl . . v c . . c , t 

to the DPC by the ATM. TTie DPC validates the biometric, < l VP e >[ X ] a Ien S lh < X > ™y of the 

and then sends the resulting financial account list along with tune a ^ ^ for stonn e Ume and dale 

the private code back to the ATM. The ATM asks the BIA to biometric a binary data type used for storing the biometric 

decrypt the response, and then displays the private code on 30 When describing database storage requirements, the term 

the ATM's display screen. In addition, the ATM also exam- "expected" means the expected condition of a fully loaded 

ines the response to see whether or not the user has caused system. 

a silent alarm to be raised during the account access. ATMs accomplish their tasks by sending messages to a 
Once the account list has been received by the ATM, the Dpc site - The DPC site sends back a response packet 
user selects an account, and performs financial operations 35 containing the status on the success or failure of the opera- 
using that and related financial accounts with the ATM, "on- 
requesting cash, depositing funds, transferring funds, inquir- Communication is via a logical or a physical 
ing about account balances, and so on. connection — oriented message delivery mechanism such as 
Messages between the ATM and the DPC are preferably x * 25 connections, TCP/IP connections, or a telephone call to 
secured by encryption and MAC calculation from the BIA. 40 a modem bank. Each session holds the connection to the 
The MAC means that the ATM cannot change the contents ATM °P en unlil tne DPC sends its response back to the 
of the message without being detected, and encryption ATM. 

prevents the encrypted part of the message from being The message contains a BIA message part and a ATM 

disclosed. message part: 

Because the BIA has no LCD or no keypad attached, it 45 BIA message part consists of; 

requires the ATM to provide all the text prompts and to protocol version number 

gather all the input from the user. message type 

Data Processing Center 4-byte BIA Identification (hardware ID) 

■ The Data Processing Center (DPC) handles user registra- 4-byte sequence number 

tion and user identification, as its main responsibilities. 50 <message specific data> 

Preferably, each DPC site is made up of a number of Message Authentication Code (MAC) 

computers and databases connected together over a LAN as ATM message part 

illustrated in the DPC Overview FIG. 2. Multiple identical <ATM specific data> 

DPC sites ensure reliable service in the face of disaster or The BIA message part is constructed by a BIA device. It 

serious hardware failure at any single DPC site. 55 includes one or two biometrics, authorization amounts, and 

Furthermore, each DPC site has electrical power backup and the contents of the general registers which are set by the 

multiple redundancy in all of its critical hardware and ATM. Note: the MAC in the BIA message part only applies 

database systems. to the BIA part and not to the ATM part. 

DPC components fall into three categories: hardware, An ATM may place additional data for the message in the 

software, and databases. Below is a short description, by 60 ATM message part. The BIA provides a message key to 

category, of each component. allow the ATM to secure the ATM part data. The BIA 

Hardware automatically includes the message key in the packet's 

Firewall Machine: the entry point of the DPC site. FW encrypted biometric block when necessary. The ATM per- 

Gateway Machine: the system coordinator and message forms the message key encryption itself, however, 

processor. GM 65 The response packet contains a standard header and two 

DPC Local Area Network: connects the DPC sites. optional free-form message parts: one with a MAC and one 

DPCLAN without: 
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Standard Header close enough comparison score, the comparisons are 

protocol version number repeated using the registered secondary biometric samples, 

message type ^ none °* toe secondary biometric have a close enough 

4-b te hardware ID comparison score, then the IBD machine returns an "user not 

. vr 5 found" error. Otherwise, the IBD machine returns the full 

4-byte sequence No. IBD record of the user, from which such fields such as the 

<message specific dala> private code, financial account numbers, and so on may be 

MAC obtained. 

Optional Free-form message pan without MAC In one embodiment, other information is present that 

additional message specific data> 10 assists the IBD machine in searching the database. For finger 

The message part with a MAC is sent to the BIAso that images, this includes information such as the classification 

it may validate that this part of the response has not been of the image (whirl, arch, etc.), and other information about 

tampered with and to display the user's private code. The the finger ridge structure that is useful for selecting out 

message part without a MAC is used for transmitting large biometrics that are not likely to match (or information on 

amounts of data that are not sent to the BIA for MAC is biometrics that are likely to match). Other methods of 

validation as the BIA to ATM connection may be of limited obtaining grouping or searching information from biometric 

bandwidth. template information are known in the industry. 

In an embodiment of the invention with multiple DPC Each entry in the VAD preferably has information on the 

sites, a ATM need only send its message to one of the DPC number of recent messages submitted, the number of recent 

sites, typically the closest, because that site automatically 20 messages that have failed, the device security assessment, 

handles updating the others by running distributed transac- whether or not the device is attended along with the fraud 

tions as necessary. detection skill of the attendant, and lastly the security 

When one of the DPC's Firewall Machines receives a problems associated with the physical location of the device 

packet, it forwards it to one of the GM Machines for the itself. 

actual processing. Each GM has a Message Processing 25 Whenever a user identification fails, the VAD record for 

Module that handles the coordination between the DPC the device is updated appropriately. Too many failures, and 

components required to process the message and sends the the Security Factor Module will take the device out of 

response back to the sender. service, refusing any further transactions from that device 

All packets the DPC receives, with the exception of those until a service representative places it back in service, 

not constructed by a BIA, contain a BIA hardware identi- 30 Protocol Messages 

fication code (the BIA Identification of the packet), a The following sections describe each protocol message/ 

sequence number, and a Message Authentication Code response and the actions the DPC takes to perform them. 

(MAC). The GM asks the MAC Module to validate the The list of protocol packets are: 

packet's MAC and then checks the sequence number with User Registration 

the Sequence Number Module. If both check out, the GM 35 ^ ser identification 

passes the packet to the Message Decrypt Module for 

decryption. If any one of the checks fail, the GM logs a 

warning, terminates processing for the packet, and returns an A™ Access 

error message to the BIA device. Account Access 

Each packet the 6PC receives may contain an optional 40 User Registration 

response key stored in the encrypted biometric block of the Registration Request 

packet. Before the DPC replies to a message that includes a 

response key, it encrypts the response packet with the 

response key. It also generates a Message Authentication 

Code and appends it to the packet. 45 

_ , rr r i.i* protocol version message type 

The only exception to encrypting response packets applies J_ byte hardware ID 

to error messages. Errors are never encrypted and never 4-byte sequence number 

include confidential information. However, most response encrypted(DUKPT key) Biometric: 

packets include a status or response code that can indicate , !I5"? yle primf ? re e istration bi ° mctric . 

, , . , . 1000-byte secondary registration biometric 

whether the request succeeded or not. 50 112-bit response key 

DPC Procedures 112-bit message key 

The DPC has three procedures commonly used while MAC 

processing messages. A ™ part: . . 

r _ , . t _ _ . . ._ , encryptcd(messaee key): 

For messages that require the DPC to identify a user, the name 

DPC executes the following procedure. Using the bid 55 address 

biometric, the DPC searches the IBD Machine List for the zipcode 

main and backup IBD machines responsible for handling P nvat ? **** , . . , _ 

., .„ . c x - . • . XT 4 . „ - financial account list (account index code, financial account #) 

identifications for the given biometric. Next, the DPC sends account index code 

the identification message to either the main or backup 

machines depending on which is the least loaded. The IBD 60 

machine responds with the IBD record for the user or a "user Registration Response 

not found" error. 

The IBD machine retrieves all the IBD records for the 

given biometric. The IBD machine compares each record's " ! \ 

. , , . . , . , , . , protocol version 

primary registered biometric sample with the user s bid 65 message type 

biometric sample arriving at a comparison score indicating 4-byte hardware DO 
the similarity of the two biometrics. If no biometric has a 
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-continued 

4- byte sequence number 
encrypted(response key): 

private code text 

biometric identification code 

list of DPC chosen biometrics 
status code (OK, fail, etc.) 
MAC 



Users register with the DPC via a User Registration ATM 
(URT). The URT sends the DPC a registration packet 
containing primary and secondary biometrics, along with 
ancillary data such as the user's name, address, a list of 
financial accounts, the private code, and the emergency 
account index code. Optionally, the user may include a 
Social Security Number (or "SSN"). In a modification step 
any previously entered data can be modified or deleted. 

Preferably, only one DPC site acts as the registration site, 
for implementation simplicity. Registration request packets 
received by non-registration DPC sites are forwarded to the 
current registration site. The registration DPC site performs 
the entire registration check,- assigning of IBD records to 
IBD machines, and the distributed transaction required to 
update all other DPC sites. 

The registration DPC site selects the biometric for the 
registration biometric, stores the IBD record on the main and 
backup IBD machines (as specified in the biometric List), 
and checks the biometric suitability of the registration 
packet before running the distributed transaction to update 
the other DPC sites. 

The DPC runs a biometric sample duplication check step 
wherein the biometric from the registration step is checked 
against all previously registered biometrics currently asso- 
ciated with the identical biometric. The DPC may reject the 
registration for the following reasons: the biometrics are 
confusingly similar to another biometric. Alternatively, the 
biometrics may be too similar to other biometrics stored, 
resulting in an unacceptable false accept rate or false reject 
rate. 

User Identification 

User Identification Message 



B1A Part: 

4-byte BIA Identification 
4-byte sequence number 
encrypted (DUKPT key) Biometric block: 
300-byte authorization 
112-bit response key 
MAC 
ATM Part: (not used) 



User Identification Response 



encrypted (response key): 
private code text 
user name 

status code (ok, failed, etc.) 

MAC 



The User Identification message includes a biometric 
block which the DPC uses with the user identification 
procedure to identify the user. If the user is identified, then 
the DPC responds with the user's name, biometric 
identification, and private code. Otherwise, the DPC 
responds with an "unknown user*' error. 



,879 

14 

Account Access 
Account Access Request Message 



5 

BIA Part: 

4-byte BIA Identification 
4-byte sequence number 
cncryptedfDUKPT key) Biometric block: 
' 300-byte authorization biometric 

112-bit response key 
30 MAC 

ATM Part: (not used) 



Account Access Response 



encrypted(response key): 
private code text 

list of(account name, account numbers) 
status code (OK, failed, etc.) 
MAC 



The Account Access message allows users to retrieve the 
list of financial accounts linked to the user's biometric. The 
25 ATM uses this list to determine which accounts the user has 
permission to perform operations upon. 

The GM identifies the user by the packet's biometric and 
retrieves the appropriate information from the user's record. 

User Support and System Administration Messakes 
3 q The DPC handles additional message types classified as 
internal messages. The DPC generally does not accept these 
messages from non-DPC systems. The messages are data- 
base vendor specific. However, the internal network uses 
DES-encrypted packets to provide additional security. 
35 The User Service and System Administration tasks are 
implemented using the database vendor's query language 
and application development tools. 
User Service tasks 

IBD: find, activate, deactivate, remove, correct records, 
40 change biometric. 

AID: add or remove authorized individuals. 

AOD: find, add, remove, correct records. 

VAD: find, activate, deactivate, remove, correct records. 
45 PFD: add, remove, correct records. 
System Administration tasks 

Run prior fraud checks. 

Modify the Valid Site List. 

Summarize log information (warnings, errors, etc.). 
50 Performance monitoring. 
Run backups. 

Crash recovery procedures. 
Time synchronization for the DPC sites. 
5S Change the primary registration site. 
Change the secret DES encryption key. 
Generate a list of BIA hardware identification code, MAC 
encryption key, and DUKPT Base Key triples. Store on 
an encrypted floppy for the Key Loading Device. 
60 DPC LAN 

The DPC Local Area Network (LAN) links the machines 
of the DPC sites together preferably using a fiber optic token 
ring. The fiber optic token ring provides both high band- 
width and good physical security. 
65 The network interfaces used by the machines on the DPC 
LAN include encryption hardware to make lapping or inter- 
cepting packets useless without the encryption key. The 
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encryption key is the same for all machines on the LAN and 
is stored in the encryption hardware. 

A properly configured network sniffer acts as am intruder 
detector as backup for the FW. If an anomalous message is 
detected, the intruding messages are recorded in their 
entirety, an operator is alerted, and the FW is physically shut 
down by the sniffer. 

Message Processing Module 

The Message Processing Module (MPM) handles the 
processing for a message. It communicates with other com- 
ponents of the DPC as necessary to perform its tasks. The 
presence of an MPM on a machine brands it as a GM. 

The MPM maintains a message context for each message 
it is currently processing. The message context includes the 
information necessary to maintain the network connection to 
the ATM making the message, the BIA device information, 
the response key, and the response packet. 

Message Authentication Code Module 

The Message Authentication Code Module's (MACM) 
tasks are to validate the Message Authentication Code on 
inbound packets and to add a Message Authentication Code 
to outbound packets. 

The MACM maintains an in-memory hash table of 112- 
bit MAC encryption keys keyed by BIA hardware identifi- 
cation code. 

When the MACM receives a request from the GM to 
validate a packet's MAC, it first looks up the packet's 
hardware identification code in the hash table. If no entry 
exists, then the MACM replies to the GM with an "invalid 
hardware identification code" error. 

Otherwise, the MACM performs a MAC check on the 
BIA message part of the packet using the 112-bit MAC 
encryption key. If the MAC check fails, then the MACM 
replies to the GM with an "invalid MAC" error. Otherwise, 
the MACM replies with a "valid MAC" message. 

If the packet contains a seller identification code, the 
MACM also checks the seller identification code against the 
owner identification code in the hash table. If the codes don't 
match, then the MACM replies with an "invalid owner" 
error. 

When the MACM receives a request from the GM to 
generate a MAC for a packet, it looks up the MAC encryp- 
tion key using the packet's hardware identification code. 
With the MAC encryption key, the MACM generates a 
MAC and adds it to the packet. If the MACM cannot find the 
hardware identification code in its hash table, it replies with 
an invalid hardware identification code error instead. 

Database Schema 

The MACM hash table entry contains: 

MACM Entry: 
hardwareld«int4 
ownerId=int4 
macEncryptionKey=intl6 

The table is hashed by hardware identification code. 

The MACM only contains records referencing active BIA 
hardware identification codes and active apparatus owners. 
Whenever an apparatus or apparatus owner is suspended or 
deleted from the system, the MACM removes any entries 
that reference the identification code. When an apparatus is 
activated, the MACM then adds an entry for it. 

The MACM also caches the MAC encryption key from 
the Valid Apparatus Database. Since the system does not 
allow the encryption key of a BIA to be changed, the MACM 
does not need to worry about receiving encryption key 
updates. 

Message Decrypt Module 

The Message Decrypt Module's (MDM) task is to recon- 
struct the DUKPT transaction key and with it decrypt the 
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bio metric block of the packet. It maintains a list of the 
DUKPT Base Keys that are required to generate the trans- 
action key. 

The MDM constructs the DUKPT transaction key using 
the packet's sequence number as the DUKPT transaction 
counter, the upper 22 bits of the BIA hardware identification 
code as the DUKPT tamper resistant security module (or 
"TRSM") Identification, and the low 10 bits of the BIA 
hardware identification code as the DUKPT Key Set Iden- 
tification. 

The DUKPT standard specifies how the transaction key is 
generated. The Key Set Identification is used to look up a 
Base Key from the Base Key List. The Base Key is used to 
transform the TRSM Identification into the initial key via a 
DES encrypt/decrypt/encrypt cycle. The transaction counter 
is then applied to the initial key as a series of DES encrypt/ 
decrypt/encrypt cycles to generate the transaction key. 

For additional security, two Base Key Lists are 
maintained, one for low security BIA devices and one for 
high security devices. The MDM chooses which Base Key 
List to use depending on the security level of the device. 

Database Schema 

The MDM Base Key List entry contains: 

MDM Entry: 
baseKey=intl6 

The Base Key List is indexed by Key Set Identification. 

The MDM maintains an in-memory list of the DUKPT 
Base Keys. Each key requires 112-bits. The MDM maintains 
two sets of 1024 keys requiring 32 KB total. 

Biometric Group List BGL) 

The Biometric Group List (BGL), in conjunction with the 
Individual Biometric Database Machine List, defines the 
configuration of the IBD machines. A BGL exists on each 
GM Machine (GM). 

The BGL maintains the list of groups in order and uses a 
binary search to quickly find the correct group. 

The initial configuration for the BGL, is one giant bio- 
metric group containing all possible biometrics. After a 
threshold number of biometrics are assigned, the giant 
biometric group is split in two. Thereafter, this process is 
applied to all succeeding biometric groups. 

When a biometric group splits, the BGL assigns a new 
main and backup IBD machine based on available storage 
on a first-come-first serve basis. The BGL coordinates with 
the IBD machines to first copy the affected records from the 
old main and backup machines to the new ones, update the 
IML record, and last remove the old main and backup 
copies. Splitting a biometric group is an involved task. The 
BGL batches split requests to be run when the DPC is lightly 
loaded, for instance, at night. 

The system administrator may also change the main and 
backup IBD machines for a given biometric group if the 
machines' free storage falls below a level required for 
handling the expected amount of new registrations. 

Database Schema 

The schema for the Biometric Group records are: 
BiometricGroup: 

lowBgv=int8 

highBgy«int8 

used=int4 

Each biometric group is identified by a unique identifier. 
For convenience the biometric group identification code is 
the lowBgv code for the group, however the system does not 
otherwise rely upon this fact. 

The BGL is keyed by the lowBgv field. 

The BGL is expected to contain about 3000 groups (each 
biometric group contains about 1000 active biometric 
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values, but may span millions of actual biometric values). 
The entire BGL requires about 72 KB of storage and is 
cached completely in memory. 

When biometric groups are added, merged, or split up, the 
BGL is responsible for informing the IBD Machine List of 5 
the changes and for directing the movement of IBD records 
from one IBD machine to another. 

Individual Biometric Database Machine List 

The IBD Machine List (IML), in conjunction with the 
Biometric Group List, codifies the configuration of the IBD 10 
machines. The IML maps a biometric value to the main and 
backup IBD machines storing IBD records for the biometric. 
The IML is actually keyed by Biometric Group (a set of 
consecutive biometric values). An IML exists on each GM 
Machine (GM). is 

When a GM processes a message that requires a biometric 
identification, the GM finds the IML record keyed by the 
biometric group. The GM then knows the main and backup 
IBD machines to use for the biometric identification. 

Most IBD records will be users, who will use the system 20 
to purchase products from sellers at points of sale. The rest 
of the records will be generally associated with people who 
perform administrative functions such as registration, or 
user support. 

Database Schema 25 

The schema for the IML list entries are: 

MachinePair: 

biometricGroup=int8 

main=int2, 

backup«int2 30 

The IML is keyed by bvgGroup. 

The IML is expected to contain about 3000 entries (the 
number of Biometric Value Groups). Each MachinePair 
record is 12 bytes requiring about 36 KB of storage and is 
cached completely in memory. 35 

Any changes in the configuration of the IBD machines are 
reflected in the IML. In addition, the IML uses Biometric 
groups for its keys so when the Biometric Group List gets 
modified, the IML is also updated. 

Sequence Number Module 40 

The Sequence Number Module's (SNM) primary func- 
tion is to prevent replay attacks by validating packet 
sequence numbers. Its secondary task is to minimize the 
effects of a resubmission attack by informing other SNMs in 
remote DPC sites of sequence number updates and to 45 
periodically update the sequence numbers in the Valid 
Apparatus Database. 

The SNM maintains an in-memory hash table of sequence 
numbers keyed by BIA hardware identification code codes 
to allow quick validation of packet sequence numbers. 50 

When the SNM receives a validate request from the GM 
for a given hardware identification code and sequence 
number, it looks up the hardware identification code in the 
hash table. If no entry exists, then the SNM replies to the 
GM with an "invalid hardware identification code" error. 55 

Otherwise, the SNM checks the given sequence number 
against the sequence number stored in the hash table entry. 
If the sequence number is less than or equal to the stored 
sequence number, the SNM replies with an "invalid 
sequence number" error. Otherwise, the SNM sets the 60 
sequence number in the hash table entry to the given 
sequence number and replies with a "valid sequence num- 
ber" message. 

From time to time, the SNM may observe a sequence 
number gap. A sequence number gap occurs when the SNM 65 
receives a sequence number that is more than one greater 
than the sequence number stored in the hash table entry. In 



other words, a sequence number was skipped. When the 
SNM discovers a sequence number gap, it replies with a 
"sequence number gap" message to the GM instead of a 
"valid sequence number" message. The GM treats the packet 
as valid, but it also logs a "sequence number gap" warning. 

Sequence number gaps usually occur when network con- 
nectivity is lost: packets are dropped or can't be sent until 
the network is restored to working order. However, sequence 
number gaps occur for fraudulent reasons as well: malicious 
parties could intercept packets preventing them from arriv- 
ing at the DPC or they could even attempt to counterfeit 
packets (with a large sequence number so that it isn't 
immediately rejected). 

The SNM's secondary function is to inform other DPCs 
of the updated sequence numbers. Quickly updating 
sequence numbers at all DPC sites thwarts resubmission 
attacks wherein a malicious entity monitors packets destined 
for one DPC site and immediately sends a copy to a different 
DPC site in the hope of exploiting the transmission delay of 
sequence number updates from one DPC site to another 
resulting in both sites accepting the packet as valid, when 
only the first site should accept the packet. 

The SNMs send update messages to each other whenever 
they receive a valid sequence number. If an SNM receives 
an update message for a sequence number that is less than 
or equal to the sequence number currently stored in its hash 
table, that SNM logs a sequence number resubmission 
warning. All resubmission attacks are detected in this man- 
ner. 

A simpler way to thwart resubmission attacks completely, 
is to have only one SNM validate packets. Under this 
scheme, there is no update transmission delay window to 
exploit with a resubmission attack. Alternately, multiple 
SNMs can be active at the same time provided none of them 
handle sequence number validation for the same B1A- 
equipped device. 

Sequence Number Maintenance 

When the SNM boots up, it loads the sequence number 
hash table from the sequence numbers for active BIA stored 
in the VAD. 

The VAD is responsible for sending add-entry and 
remove-entry messages to the SNMs for any BIA-equipped 
devices that are activated or deactivated to keep the SNM 
hash table up-to-date. 

Database Schema 

The SNM hash table entry contains: 

SNM Entry: 
hardwareld=int4 
sequence Number«int4 

The hash table is keyed by hardwareld. 

Assuming about 5 million BIA-equipped devices in ser- 
vice requires the hash table to be about 40 MB. 

The SNM depends on the Valid Apparatus Database. 
When an apparatus is suspended or removed from the 
database, the SNM removes the corresponding entry. When 
an apparatus is activated, the SNM creates an entry for it. 

The SNMs require a transmission bandwidth of about 8 
KB per second to handle 1000 update sequence number 
messages per second. The update sequence number mes- 
sages is buffered and sent out once per second to minimize 
the number of actual messages sent. 

Apparatus Owner Database 

The Apparatus Owner Database (AOD) stores informa- 
tion on users or organizations that own one or more BIA- 
equipped devices. This information is used to double check 
that the BIA devices are used only by their rightful owners, 
to provide financial account information, and to allow iden- 
tification of all BIAs owned by a specific user or organiza- 
tion. 
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Database Schema 

The schema for the Apparatus Owner record is: 
ApparatusOwner: 
ownerId-int4 
name=char50 
address=char50 
zipCode=char9 
status=intl 

The status field is one of: 
0: suspended 
1: active 

The Apparatus Owner Database is keyed by ownerld. 
The AOD is stored as a hashed file keyed by owner 
identification code. A copy of the AOD is stored on each 
GM. 

When entries are removed or suspended from the AOD, 
any Valid Apparatus Database records that reference those 
apparatus owners are marked as suspended. In addition, the 
MAC Module and the Sequence Number Module remove 
their entries for the suspended apparatuses. 
2,i>^ Valid Apparatus Database 

The Valid Apparatus Database (VAD) is a collection of 
records representing all of the BIAs that have been manu- 
factured to date. The VAD record contains the Message 
Authentication Code encryption key for each BI A, as well as 
an indication of whether a BIA is active, awaiting shipment, 
or marked as destroyed. In order for a message from a BIA 
to be decrypted, the BIA must exist and have an active 
record in the VAD. 

When manufactured, each BIA has a unique public iden- 
tification code. In addition, each BIA is injected with a 
unique MAC encryption key, and an initial DUKFT key, all 
of which are entered into the VAD record prior to BIA 
deployment. 

When a BIA is first constructed, it is given a unique 
hardware identification code. When a BIA is placed in 
service, its hardware identification code is registered with 
the system. First, the owner or responsible party of the BIA 
is entered into the Apparatus Owner Database (AOD). Then, 
the VAD record is pointed to the AOD record, and the BIA 
is then set active. Messages from that BIA are accepted by 
the DPC 

When a BIA enters service, the installing agent performs 
an attendant security assessment, determining the relative 
attentiveness the organization pays towards fraud-fighting 
and the like. Likewise, the geography of the surrounding 
area is examined; high crime neighborhoods will merit a 
lower security value, for instance. These values are place in 
the VAD record for the device. These can change over time. 

When a BIA is removed from service, it is marked as 
inactive, and the link to the AOD record is broken. No 
communications from that BIA are accepted. 
jfa} Each type and model has a device security assess- 
ment performed on it during its design and construction. 
This represents the basic ability of the device to resist 
attempts to monitor the BLA's internal functioning, the 
ability of the BIA to keep both past and current encrypVion 
keys stored on the BLA secret, and the BIA's ability to resist 
reprogramming by criminals. 

The number of failed messages, recent messages, and the 
average number of messages performed by a given appara- 
tus are recorded in the VAD record, to assist the security 
factors module in detecting fraudulent messages. 
Periodically, the recentReqs and the failedReqs fields are 
cleared. 
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Database Schema 

The schema for the Valid Apparatus record is: 
Valid Apparatus: 
hardware Id»int4 
5 macEncryptionKey«intl6 
ownerId=int8 
mfgDate=time 
inServiceDate=time 
deviceSecurity=int2 
jo locationSecurity=int2 
attendentSkill=int2 
failedReqs«int2 
recenlReqs=int2 
avgReqs=int2 
15 status-intl 

Possible values for the status field are: 
0: suspended 
1: active 
^4 2: destroyed 
20 ^ The Valid Apparatus Database is keyed by the hardware 
identification code. 

The VAD is stored as a hashed file keyed by hardware 
identification code. A copy of the VAD is stored on each 
GM. 

25 When a VAD record changes status, the MAC Modules 
and Sequence Number Modules are informed of its change 
in status. For instance, when an apparatus becomes active, 
the MACP and SNM adds an entry for the newly active 
apparatus. When an apparatus becomes inactive, the MACP 

30 and SNM remove their entry for the apparatus. 
Individual Biometric Database 

Individual Biometric Database (IBD) records store per- 
v sonal information on users for both identification as well as 
authentication. This information may include their primary 

35 and secondary biometrics, one or more biometric values, a 
list of financial accounts, perhaps an account index code, 
account index names, private code, one or more emergency 
account index codes, address, and phone number. The user 
may optionally include this SSN. This information is nec- 

40 essary for identifying a user either by biometric or personal 
information, for accessing related information, or for pro- 
viding an address or phone number to remote sellers or 
banks for additional verification. 

Users are added to the system during the user enrollment 

45 process at registered User Registration ATMs located in 
retail banking establishments worldwide, or in local system 
offices. During enrollment, users add financial accounts and 
optionally any personal identification numbers, to their 
biometrics. 

50$° The IBD exists on multiple machines, each of which is 
responsible for a subset of the IBD records with a copy of 
each record stored on two different machines, both for 
redundancy and for load-sharing. The IBD Machine List, 
stored on the GM, maintains which machines hold which 

55 biometric values. 
Database Schema 

The schema for the User Biometric record is: 
UserBiometric: 

primaryBiometric=biometric 
60 secondaryBiometric=biometric 

biometricId=int4 

phoneNumber=charl2 

lastName«char24 

firstName=char24 
65 middle lnilial=char2 

SSN«char9 

privateCode-char40 
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address-charSO 

zipCode*=char9 

publicKey*=char64 

checksum s»int4[10] 

accountIndexCodes=char30[10] 

accountIndexNames«char30[10] 

emergencyIndexCode=charl 

emergencyLink=charl 

privs=charlO 

enroller«int8 

silentAlarmCount=int4 

silenlAlarmBehavior=int2 

status=intl 
The status field Ls one of: 

0: suspended 

1: active 

2: priorFraud 
The IBD is keyed by the biometric value. 
Each IBD machine, preferably, has additional indexes on 
the user's Social Security Number, last name, first name, and 
phone number to facilitate access to the IBD database. 
—Each IBD machine has 40 GB of secondary storage 
provided by one or more RAID devices. Each IBD record is 
2658 bytes (assuming the biometrics are IK apiece) allow- 
ing up to 15 million records per machine. The IBD records 
are stored using a (sometimes clustered) secondary index on 
the biometric value. The index is stored in memory and 
requires no more than 64 MB (a 64 MB index handles about 
16 million entries). To store records for 300 million users, 
the DPC needs at least 40 IBD machines: 20 IBD machines 
for main storage and another 20 for backup. The number of 
IBD machines is easily scaled up or down depending on the 
number of registered users. 

The IBD machines, Biometric Group List, and the IBD 
Machine List remain up-to-date in terms of which biometric 
values are on which machine. When a biometric group is 
reconfigured or main and backup machines for biometric 
groups are changed, the IBD machines update their data- 
bases and indexes appropriately. 
Authorized Individual Database 

For each issuer or personal BIA-equipped device, the 
Authorized Individual Database (AID) maintains a list of 
users who are authorized, by the owner of the device, to use 
it. 

The AID exists because it provides restricted access to a 
ATM. 

Database Schema 

The schema for the Authorized Individual record is: 

Authorized Individual: 
hardwareld=int4 
biometricId=int4 

The hardwareld refers to a record in the Valid Apparatus 
Database and the biometricld refers to a record in the 
Individual Biometric Database. Whenever the DPC needs to 
check whether an individual is authorized to use a personal 
or issuer BLA device, the DPC checks for the existence of an 
Authorized Individual record with the correct hardwareld 
and biometricld. 

Personal BIA devices are identified by a use field set to 1 
(personal) in the Valid Apparatus Database. Issuer BIA 
devices are identified by a use field set to 2 (issuer) in the 
Valid Apparatus Database. 

System Performance 
In GM: 

1. MACM checks the MAC (local) 

2. SNM checks- the sequence number (network message) 

3. MDM decrypts the biometric block (local) 
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4. Find IBD machine (local) 

5. Send identify message to the IBD machine (network 
message) 

In IBD machine: 
5 6. Retrieve all IBD records for the Biometric Value (x 
seeks and x reads, where x is the number of pages 
required to store the biometric records). 
7. For each record, compare against its primary biometric 
(y/2 ms where y is the number of records retrieved). 
10 8. If no reasonable match, repeat step 9 but compare 
against the secondary biometric (z*y/2 ms, where y is 
the number of records retrieved and z is the probability 
no match is found). 
5 9. Update the best matching IBD record's checksum 
queue and check for possible replay attacks (1 seek, 1 
read, and 1 write). 

10. Return the best matching IBD record or an error if the 
match is not close enough (network message). 

20 In GM: 

11. Authorize message with an external processor 
(network message) 

12. GM encrypts and MACs the response (local). 

13. Sends response packet back (network message). 
25 Use-Sensitive DPC Procedures 

In another embodiment, the system has use-sensitive data 
processing capabilities, wherein frequent users of the system 
are on a local cache. This system comprises a master DPC 
having a master DPC comparison engine, also referred to as 

30 a comparator. The master DPC comparator further has a 
master user biometric database which contains or stores the 
biometric samples of all users registered with the identifi- 
cation computer system. The master DPC further comprises 
a user biometric group database which contains the biomet- 

35 rics of said users. Biometrics of users may not necessarily be 
unique to the individual users, thus, more than one user can 
have the same biometric. The system further comprises at 
least two local DPCs which are physically apart from each 
other. Each local DPC further comprises a local compara- 

40 torand a local user biometric database containing a subset of . 
the biometric samples contained in the master biometric 
database. Dala communications lines allows messages to 
flow between each local DPC and the master DPC. 
To perform an identification, the BIA sends the appropri- 

45 ate message to the local DPC, where the comparator com- 
pares the bid biometric sample against the subset of the 
registered biometric samples contained in the local DPC 
databases to produce either a failed or successful first 
identification result. If the local DPC returns a failed iden- 

50 tification result, the bid biometric sample is transmitted to 
the master DPC for comparison of the entered bid biometric 
sample to the biometric samples stored in the master DPC 
for producing either a failed or successful second identifi- 
cation result. If both identifications fail, the person is not 

55 identified. Otherwise, the result of the first or second iden- 
tification result is externalized from the identification com- 
puter system to the user by the BIA and/or ATM. 

If the local DPC could not identify the individual, but the 
master DPC could, the master DPC transmits the database 

60 record of the identified user to the local DPC. Therefore, in 
future bid biometric samples presented by the same 
individual, the local DPC will be able to identify the user 
without involving the master DPC. 

n another embodiment of the invention the identification 

65 computer system further comprises a purge engine for 
deleting database records from the local DPC databases. In 
order to store only records for those individuals who use the 
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system often and prevent the overload of databases with 
records from individuals who do not use the system often or 
use the local DPCs sparsely, the record of a user is deleted 
from the local DPC biometric databases if there has been no 
attempt to identify an individual upon expiration of a 
predetermined time limit. 

In order to make communications between the master 
DPC and the local DPCs more safe, the system further 
comprises encryption and decryption means, wherein com- 
munications between the master DPC and local DPC are 
encrypted. 

The master DPC is responsible for storage of the entire set 
of biometric samples registered with the computer system. 
Each master DPC is preferably made up of a number of 
computers and databases connected together over a LAN 
(known in the industry) as illustrated in the master DPC 
overview FIG. 2. Multiple identical master DPC sites ensure 
reliable service in the face of disaster or serious hardware 
failure at any single Master DPC site. Furthermore, each 
master, intermediary, and local DPC site has electrical power 
backup and multiple redundancy in all of its critical hard- 
ware and database systems. 

It is preferred that the master and intermediary DPCs have 
a firewall machine which is the entry point of data and 
messages into these computers, and a gateway machine 
which is a system coordinator and message processor. 

Firewall Machine 

The FW Machines provide a first line of defense against 
network viruses and computer hackers. All communication 
links into or out of the DPC site first pass through a secure 
FW Machine. 

The FW Machine, an Internet-localnet router, only 
handles messages destined for the GM Machines. BIA- 
equipped ATMs send packets to a single DPC site via 
modem, X.25, or other communication medium. The DPC 
relies on a third party to supply the modem banks required 
to handle the volume of calls and feed the data onto the DPC 
backbone. 

For DPC to DPC communication, primarily for distrib- 
uted transactions and sequence number updates, the FW 
Machines send out double-length DES encrypted packets. 
The DPC LAN component handles the encryption and 
decryption: the FWs do not have the ability to decrypt the 
packets. 

A properly configured network sniffer acts as an intruder 
detector as backup for the FW. If an anomalous message is 
detected, the intruding messages are recorded in their 
entirety, an operator is alerted, and the FW is physically shut 
down by the sniffer. The FW disallows any transmissions 
from the internal network to the rest of the Internet. 

An electronic financial transaction message requires 
about 400 bytes and registration packets require about 2 KB. 
To handle 1000 electronic financial transactions per second 
and 1 registration packet per second, the FW Machines are 
able to process about 400 KB per second. Each DPC site 
requires an aggregate bandwidth of nearly three Tl connec- 
tions to the third party modem bank and the other DPC sites. 

Gateway Machine 

The GM Machine (GM), through the FW Machines, link 
the outside world (BI A-equipped ATMs and other DPCs) to 
the internal components of the DPC. The DPC has multiple 
GMs, typically two. 

The GM supervises the processing of each BIA message, 
communicates with the various DPC components as 
necessary, and sends the encrypted results of the message 
back to the sender. The software performing this task is 
called the Message Processing Module. 
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The GM logs all messages it receives and any warnings 
from components it communicates with. For example, the 
GM logs any silent alarms, sequence number gaps, and 
invalid packets. 

Processing a message may require the GM to inform GMs 
at all other DPCs of a change in the DPC databases. When 
this happens, the GM runs a distributed transaction to update 
the remote databases. 

Distributed transactions fall into two categories: synchro- 
nous and asynchronous. Synchronous distributed transac- 
tions require the GM to wait for the distributed transaction 
to commit before continuing to process the packet. Asyn- 
chronous distributed transactions do not require the GM to 
wait for the commit, and allow it to finish processing the 
message regardless of whether the distributed transaction 
commits or not. Asynchronous distributed transactions are 
only used to update data for which database consistency is 
not an absolute requirement: sequence numbers and biomet- 
ric checksum recordings may be performed asynchronously, 
whereas creating database records, such as User Biometric 
records, may not. 

When executing a synchronous distributed transaction, 
the requesting GM only considers the entire transaction 
successful if all sites can successfully commit the transac- 
tion locally. Otherwise, the GMs back out the changes 
locally and reject the request due to a transaction error. 

The list of valid DPC sites is normally all of the sites. In 
the case of an extreme site failure, however, a system 
administrator may manually remove that site from the valid 
site list. The most likely cause of distributed transaction 
failures, however, are temporary network failures that are 
unrelated to any DPC equipment. Messages that require a 
synchronous distributed transaction cannot be performed 
until network connectivity is restored or the site is removed 
from the valid site list. Before a site can be added back to the 
valid site list, the system administrator brings the site's 
databases up to date with those of a currently active site. 

Software Components 

Each GM runs the following software components locally 
for performance reasons: 

Message Processing Module 

Message Authentication Code Module 

Message Decrypt Module 

Individual Biometric Database Machine List 

The message bandwidth required by the GMs is similar to 
that required by the FW Machines. A FDDI network inter- 
face provides 100 MBits per second and easily covers any 
bandwidth requirements. 

From the foregoing, it will be appreciated how the objects 
and features of the invention are met. 

First, the invention provides a computer identification 
system that eliminates the need for a user to possess and 
present a physical object, such as a token, in order to 
authorize a transaction. 

Second, the invention provides a computer identification 
system that is capable of verifying a user's identity, as 
opposed to verifying possession of proprietary objects and 
information. 

Third, the invention verifies the user's identity based upon 
one or more unique characteristics physically personal to the 
user.' 

Fourth, the invention provides an identification system 
that is practical, convenient, and easy use. 

Fifth, the invention provides a system of secured access to 
a computer system that is highly resistant to fraudulent 
transaction authorization attempts by non-authorized users. 

Sixth, the invention provides a computer identification 
system that enables a user to notify authorities that a 
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particular access request is being coerced by a third party number using the account index code from the account 

without giving notice to the third party of the notification. access request message. 

Although the invention has been described with respect to 6. The method of claim 5 wherein the account index code 

a particular tokenless identification system and method for comprises an alphanumeric code. 

its use, it will be appreciated that various modifications of 5 7. The method of claim 5 further comprising an account 

the apparatus and method are possible without departing name display step, wherein a list of accounts with their 

from the invention, which is defined by the claims set forth account index codes is retrieved and displayed to the user 

below. after a successful identification. 

What is claimed is: 8. The method of claim 5 wherein during the user regis- 

1. A computer implemented method for tokenless biomet- 3Q tration step, the user registers an emergency account index 
ric access to financial accounts at an institution using an code, which if entered by the user during the initiation step 
automated teller machine, the method comprising the steps in place of the account index code, triggers a silent alarm, 
of: whereby authorities are notified of a coerced account access. 

a. a user registration step, wherein a user registers with an 9. The method of claim 8 wherein during the registration 
electronic identicator one or more registration biomet- step, the user specifies any combination of actions taken 
ric samples and one or more user financial accounts; 15 upon the triggering of the silent alarm, comprising artificial 

b. an initiation step, wherein the user initiates an account financial resource limits, presentation of a false private code, 
access at an automated teller machine by submitting at rejection of the account access, dispensing marked bills, 
least one bid biometric sample directly from the user's notifying the authorities, or the sending of the silent alarm 
person, wherein no portable man-made memory t0 tne institution. 

devices such as smartcards or swipe cards are used by 20 10- Th e method of claim 1 wherein the user registers an 

the user- emergency index during the registration step which, if 

c. at least' one transmission step, wherein an account entered by the user during the initiation step, triggers 

access request message comprising the user's bid bio- a ^T 1 *™ * L j * i ■ i u ■ * L . . j . n 

* - * c -i j * .u . . a . it u- 11. The method of claim 1 wherein the automated teller 

metric is forwarded from the automated teller machine . . • . f o , „ rt • 

..... 9 e machine is remote trom the institution and communicates 

to the electronic identicator; " „ • t -^ lt - „ „ • _ „ na ^, nw .u 

' with the institution using a computer network. 

d. a user identification step, wherein the electronic iden- 12. The method of claim 11 wherein the computer oet- 
ticator compares the bid biometric sample in the ^oik & one or more 0 f tne group comprising an automated 
account access request message with a registration teller machine network, the Internet, a private intranet, a 
biometric sample, to produce either a successful or telephone network, or a cable TV network. 

failed identification of the user; 30 13. The method of claim 1 wherein the user registration 

e. an account retrieval step, wherein upon successful step further comprises comparing the user's registration 
identification of the. user, at least one financial account biometric samples to previously designated biometric 
of the user is retrieved' and samples of certain users wherein if a match occurs, the user 

f. an access step, wherein after successful identification of „ 15 determined to have re-registered, whereby users who have 
the user and successful financial account retrieval, the 35 Pirated fraud on the system can be automatically tden- 

„ . 4 c - , , lined from their biometrics alone when they re-register, 

user is allowed to access the user financial account. - A ™ t . , - , . 1 - , . , J . °. 

jy Tt- .i_ j r i • i l • *i_ ■ * *• 14. The method of claim 13 wherein the registration step 

2. The method of claim 1 wherein the user repstrat.on rises the biometdc sa ^ les fronl * 

step further comprises registering a user personal identifi- specific fi whereby the syslem can delecl 

cation number with the electronic identicator, used by the ^ re . registra , iolls 0 f previously designated biometric samples 

electronic identicator to identify the user. Q j ^^{ n users 

3. The method of claim 1 further comprising a financial 15 -r^ me thod of claim 1 wherein the biometric sample 
operation step, wherein the user performs at least one action jg selected from any of the set of: a fingerprint, a retinal 
selected from the group comprising: withdrawing cash, image, an iris image, a facial scan and a voice print, 
depositing funds, transferring funds between accounts, 45 16. The method of claim 1 further comprising a biometric 
obtaining account balances, purchasing products, paying theft resolution step, wherein a biometric sorting number of 
bills, and obtaining electronic cash. the user is changed to prevent unauthorized access by 

4. The method of claim 1 further comprising an electronic individuals who have obtained the user's personal authen- 
identicator authentication step wherein a private code, dis- tication information. 

tinct from a PIN and not used to gain access to the electronic 5Q 17. The method of claim 1 wherein the automated teller 

identicator, is gathered from the user during the user regis- machine comprises an application executing on a personal 

tration step and is presented to only the user during a computer. 

presentation step, whereby the user is assured that the ig. a computer implemented method for tokenless bio- 
authentic electronic identicator was used to process the me t r i c access to financial accounts in institutions using an 
account access because a false electronic identicator would 55 automated teller machine, and selecting from among differ- 
not be able to present the user's private code. e nt financial accounts, the method comprising the steps of: 

5. The method of claim 1 further comprising a user a. a user registration step, wherein a user registers with an 
account retrieval step, wherein: electronic identicator one or more registration biomet- 

a. the user registration step further comprises assigning an n C samples, one or more user financial accounts, and 
account index code to a user financial account; 60 assigns an account index code to a user financial 

b. an account specification step, wherein the user enters an account; 

account index code; b. an initiation step, wherein the user initiates an account 

c. the transmission step further comprises including the access at an automated teller machine by entering at 
account index code in the account access request mes- least one bid biometric sample directly from the user's 
sage; and 65 person, wherein no portable man-made memory 

d. an account retrieval step further comprises the elec- devices such as smartcards or swipe cards are used by 
tronic identicator retrieving the user financial account the user; 
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c. an account specification step, wherein the user enters an registration biometric sample, to produce either a suc- 
account index code; cessful or failed identification of the user; 

d. at least one transmission step, wherein an account b. a biometric input apparatus for submission of the user's 
access request message comprising the bid biometric biometric samples to the electronic identicator, 

data and the account index code is forwarded from the 5 c. at least one financial account; 

automated teller machine to the electronic identicator; d. an account retrieval module, wherein upon successful 

e. a user identification step, wherein the electronic iden- identification of the user, at least one financial account 

■ , • j , • • * * „ of the user is retrieved; and 

ticator compares the bid biometric data in the account . , , » " 

. , . . . , . . . e. an execution module for debiting and crediting the 

access request message with the registration biometnc , ^ . B & 

. 7 j c i r "i * • « 10 user s financial account; 
samples to produce either a successful or failed iden- 

tification of the user- wherein after successful identification of the user and 

' successful financial account retrieval, the user is 

f. an account retrieval step, wherein upon successful allowed to access the user financial account; 
identification of the user, a financial account number of wherejn nQ man made lokens such M cards 0f smart . 
the user is retrieved using the account index code from J5 cards afe presented for submitting a bid biometric 
the account access request message; and sample 

g. an access step, wherein after successful identification of 23. The device of claim 22 wherein the user registers a 
the user and successful financial account number user personal identification number with the electronic 
retrieval, the user is allowed to access the user financial identicator, which is used by the electronic identicator to 
account. 20 identify the user. 

19. The method of claim 18 wherein the user registration 24. The device of claim 22 further comprising an elec- 
step further comprises registering a user personal identifi- tronic identicator authentication module wherein a private 
cation number with the electronic identicator, used by the co de, distinct from a personal identification number and not 
electronic identicator to identify the user. use( j t 0 gain access to the electronic identicator, is gathered 

20. The method of claim 18 further comprising an elec- 2 5 from the user during the user registration step and is pre- 
tronic identicator authentication step wherein a private code, sented to only the user during a presentation step, whereby 
distinct from a PIN and not used to gain access to the t he user is assured that the authentic electronic identicator 
electronic identicator, is gathered from the user during the was used to process the account access. 

user registration step and is presented to only the user during 25. The device of claim 22 further comprising a user 

a presentation step, whereby the user is assured that the 30 account retrieval module, wherein the user assigns an 

authentic electronic identicator was used to process the account index code to a user financial account during 

account access because a false electronic identicator would registration. 

not be able to present the user's private code. 26. The device of claim 25 further comprising a user 

21. The method of claim 18 wherein the account index account retrieval module, wherein the electronic identicator 
code comprises an alphanumeric code. 35 retrieves the user financial account number using an account 

22. A computerized device for tokenless biometric access index code contained in the account access request message, 
to financial accounts at an institution using an automated 27. The device of claim 22 wherein the user's registration 
teller machine, the device comprising: biometric samples are compared to previously designated 

a. an electronic identicator for comparing the bid and biometric samples of certain users wherein if a match 

registration biometric samples of a user, wherein the 40 occurs, the user is determined to have re-registered, 
electronic identicator compares the bid biometric 

sample in an account access request message with a ***** 
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UNITED STATES PATENT AND TRADEMARK OFFICE 

CERTIFICATE OF CORRECTION 



PATENT NO. : 6,154,879 Page 1 of 1 

DATED : November 28, 2000 

INVENTOR(S) : Pare, Jr. et al. 



It is certified that error appears in the above-identified patent and that said Letters Patent is 
hereby corrected as shown below: 



Title page. 

Attorney, Agent, or Firm, "Marger Johnson & McCollom, P.C." should read 
-- Ali Kamarei, Esq. -- 

Column 2, 

Line 23, "mains" should read - remains --; 

Line 25, "horizon" should read -- authorize --; 

Line 27, "N out" should read -- without --; 

Line 40, "else" should read - forced the --; 

Line 44, "may also phone" should read -- may also store phone --; 

Line 46, "transaction try" should read -- transaction history --; 

Column 13, 

Line 48, "300-byte authorization" should read -- 300-byte authorization biometric --; 
Column 14, 

Line 29, "messakes" should read -- messages -; 
Column 18, 

Line 48, "hardware Id" should read -- hardware Id --; 
Column 21, 

Lines 50 and 52, "hardware Id" should read -- hardware Id --. 



Signed and Sealed this 



Third Day of June, 2003 




JAMES E. ROGAN 
Director of the United States Patent and Trademark Office 
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